Timestamp-based association of identifiers

ABSTRACT

Systems and methods for associating sessions of encrypted identifiers are provided. A collection of data packets received during one or more sessions within a time period may be retrieved. Each packet in the collection may be associated with a unique identifier of a respective session. An epoch time may be calculated for each of the retrieved data packets based on the determined skew and respective timestamp information of the data packet. It may be identified as to whether each of the calculated epoch times matches a previously calculated epoch time for a packet associated with a previous session or a session that has previously been associated with a selected session. The timestamp information may be associated with a browser identifier and subject to encryption/decryption by an identifier server or authorized parties.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation-in-part of U.S. patentapplication Ser. No. 15/469,162 filed Mar. 24, 2017, now U.S. Pat. No.10,715,413, the present application is also a continuation-in-part ofU.S. patent application Ser. No. 16/697,079 filed Nov. 26, 2019, whichis a continuation of U.S. patent application Ser. No. 14/861,993 filedSep. 22, 2015, now U.S. Pat. No. 10,491,451, the disclosure of each ofthe foregoing being incorporated by reference herein.

BACKGROUND ON INVENTION Field of the Invention

The present invention generally relates to websites and applications.More specifically, the present invention relates to timestamp-basedassociation (e.g., of the same device) of identifiers.

Description of the Related Art

The use of Internet and web resources is nearly ubiquitous throughoutthe industrialized world. Users generally access the Internet using anyof a number of computing devices capable of communicating over acommunication network, whether wirelessly or through wired connections.More specifically, the user may use an application (e.g., browser) on acomputing device to access content on any of a number of webpages andwebsites hosted by one or more web and application servers. As usedherein, references to browser and browser identifier are illustrativeand should not be construed to exclude other types of applications. Onthe contrary, the present disclosure is applicable to and inclusive of avariety of applications.

Upon request, content related to a designated webpage may be downloadedto the user computing device, which may further render the webpage to bedisplayed. Such downloaded content may include a variety of differenttypes of files, including documents, graphics, audio and video, etc., aswell as related data (e.g., metadata including consent data regardinghow such information is to be used and not used). The downloaded contentmay be stored in a browser storage. Various elements and components of aparticular webpage or website may change over time (e.g., as a publisherpublishes new or updated content). Some components or elements, however,remain static and unchanged. When the user leaves the webpage and laterwishes to return, the browser storage allows the computing device toretrieve static, unchanged files related to the associated webpage fromlocal memory, rather than re-downloading the same web objects when auser wishes to revisit the webpage.

Currently, browsers do not contain or expose any unique identifiers thatcan be accessed and used by websites. Present websites and webpages maycapture data regarding the activity (e.g., repeat visits) of the user inrelation to a particular webpage. Such data may include stateinformation (e.g., preferences, shopping cart items), provideregistration or authentication information (e.g., user names, passwords,addresses/locations), or otherwise track browsing history (e.g., whichwebpages were visited, a number of visits, when the visits occurred).Because nearly all aspects of modern life may be reflected in orotherwise involve Internet activity, however, some of the tracked datamay be personally identifiable of a particular individual. Trackingmechanisms (e.g., that may or may not encompass such personallyidentifiable data) may therefore risk exposure of personal,confidential, and/or otherwise sensitive user information. In theinterests of protecting user privacy, some jurisdictions may even havestatutes or regulations restricting the type of data that may betracked.

Meanwhile, various publishers, service providers, and related entitiesmay be interested in obtaining statistical data regarding the uniquetraffic or activity in relation to a given webpage or website. Althougha web server may be able to identify a number of download requests for aparticular webpage, such requests may be made by the same user (or thesame small set of users) or device(s). Such a metric may therefore failto present an accurate picture of the traffic or other device activityinvolving the website, while using the more particularized datadiscussed above may risk exposure of information that is personallyidentifiable of a specific user.

Moreover, a browser may be used to visit multiple websites. Data istypically partitioned between different websites, as well as betweendifferent browsers. Because such different browsers generally do notcommunicate or exchange information, it can be quite difficult to get afull picture of how such a user may use a device to access and engagewith the Internet. Further complications arise when multiple browsersare considered. A device may use different browsers and other types ofapplications to visit a variety of different websites and contentproviders. Such variety can complicate the ability to track trafficwhere, for example, a device may have different browsers or applicationsused to access the same website.

There is, therefore, a need in the art for proved systems and methodsfor timestamp-based association of different identifiers.

Summary of the Claimed Invention

Embodiments of the present invention may include systems and methods fortimestamp-based association of identifiers. A collection of data packetsreceived during one or more sessions within a time period may beretrieved. Each packet in the collection may be associated with a uniqueidentifier. An uptime (which may also be referred to as epoch time) maybe calculated for each of the retrieved data packets based on thedetermined skew and respective timestamp information of the data packet.It may be identified as to whether each of the calculated epoch timematches a previously calculated epoch time for a packet associated witha previous session or a session that has previously been associated witha selected session. The timestamp information may be associated with abrowser identifier, which may be subject to encryption/decryption by anidentifier server or authorized parties. In some embodiments, bothbrowser identifier and associated device identifier may be encryptedtogether into an encrypted identifier container (e.g., EID).

Further embodiments include non-transitory computer-readable storagemedia having embodied thereon a program executable by a processor toperform a method for session association of identifiers as describedabove.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 illustrates an exemplary network environment in which a systemfor timestamp-based association of identifiers may be implemented.

FIG. 2 is a flowchart illustrating a method for timestamp-based sessionassociation.

FIG. 3 is a flowchart illustrating an exemplary method fortimestamp-based matching of encrypted identifiers.

FIG. 4 is a diagram illustrating an exemplary system for assignment anduse of encrypted identifiers.

FIG. 5 illustrates an exemplary computing system that may be used toimplement an embodiment of the present invention.

DETAILED DESCRIPTION

Embodiments of the present invention allow for session association ofidentifiers are provided. A collection of data packets received duringone or more sessions within a time period may be retrieved. Each packetin the collection may be associated with one or more unique identifiersof a respective session. An uptime—which may also be referred to as anepoch time—may be calculated for each of the retrieved data packetsbased on the determined skew and respective timestamp information of thedata packet. It may be identified as to whether each of the calculatedepoch time matches a previously calculated epoch time for a packetassociated with a previous session or a session that has previously beenassociated with a selected session. The timestamp information may beassociated with a browser identifier(s) and device identifier(s), bothof which may be subject to encryption/decryption by an identifier serverbefore storage. The encrypted identifiers may later be decrypted byauthorized parties.

FIG. 1 illustrates a network environment 100 in which a system fortimestamp-based analysis of identifiers may be implemented. Networkenvironment 100 may include a communication network 110, one or moreuser devices 120A-D, server 130 (e.g., web server), identifier server140, and one or more service providers 150. Devices in networkenvironment 100 may communicate with each other via communicationsnetwork 110.

Communication network 110 may be a local, proprietary network (e.g., anintranet) and/or may be a part of a larger wide-area network. Thecommunications network 110 may be a local area network (LAN), which maybe communicatively coupled to a wide area network (WAN) such as theInternet. The Internet is a broad network of interconnected computersand servers allowing for the transmission and exchange of InternetProtocol (IP) data between users connected through a network serviceprovider. Examples of network service providers are the public switchedtelephone network, cellular or mobile service providers, a cable serviceprovider, a provider of digital subscriber line (DSL) services, or asatellite service provider. Communications network 110 allows forcommunication between the various components of network environment 100.

Users may use any number of different electronic user devices 120A-D,such as general purpose computers, mobile phones, smartphones,smartwatches, wearable devices, personal digital assistants (PDAs),portable computing devices (e.g., laptop, netbook, tablets), desktopcomputing devices, handheld computing device, or any other type ofcomputing device capable of communicating over communication network110. User devices 120 may also be configured to access data from otherstorage media, such as local browser storage, memory cards, or diskdrives as may be appropriate in the case of downloaded services. Userdevice 120 may include standard hardware computing components such asnetwork and media interfaces, non-transitory computer-readable storage(memory), and processors for executing instructions that may be storedin memory.

In addition, user devices 120 may include a variety of applications,including browser applications that allow the user to request certainwebpages and other network accessible data. As used herein, referencesto browser and browser identifier are exemplary, and teachings regardingthe same are applicable to other types of applications and mobileadvertising identifiers (MAIDs), which may include Apple IDFA, GoogleAdID, etc. As discussed herein, multiple different types of identifiers(e.g., browser identifier(s), device identifier(s), etc.) may begenerated and associated together. For example, a particular device maybe used to access a uniform resource locator (URL) via a browserapplication. Such a browser may send such request to an associated webserver (e.g., server 130), receive responsive data (e.g., webpage filewith references to other files to download), and use such responsivedata to render and display the requested webpage. Webpage files that maybe downloaded to the user device 120 may include not only filescorresponding to content that is actually displayed as part of thewebpage, but also associated files.

Server 130, identifier server 140, and service providers 150 may includeany type of server or other computing device as is known in the art,including standard hardware computing components such as network andmedia interfaces, non-transitory computer-readable storage (memory), andprocessors for executing instructions or accessing information that maybe stored in memory. The functionalities of multiple servers may beintegrated into a single server. Any of the aforementioned servers (oran integrated server) may take on certain client-side, cache, or proxyserver characteristics. These characteristics may depend on theparticular network placement of the server or certain configurations ofthe server.

Server 130 may be any kind of server used to host web and other onlinecontent, including any type of webpage or website data. The particularfiles associated with each website may be controlled by a publisher (ordesignated administrator). The website file may include links to filesunder control by other parties. In that regard, the website filesdownloaded from server 130 may include a reference (e.g., URL) to anidentifier object, as well as an optional loader application (e.g.,Javascript commands) and associated code library to be used with theidentifier object. Such identifier object may be specific to thewebsite. For example, an identifier for a particular website may includeor otherwise be based on a domain (or other characteristic) of thatwebsite. As such, each website visited by a particular user device usinga particular browser (or other application) may be associated with aunique and different identifier.

A browser identifier may be associated with different browser sessionson a device. Because different browser and different browser sessionsmay be used on the same device, various indicators (e.g., timestamp) maybe used to associate such different browsers and sessions to a commondevice. Further, each session may likewise be associated with certainidentifiers, including TLS session identifier, TLS session ticket, etc.,as discussed below. Over time, a specific browser of a specific devicemay be assigned different browser identifiers over time, and suchbrowser identifiers may be mapped based on certain common indicators soas to identify that such browser identifiers are associated with thesame browser.

The identifier server 140 may further be able to draw associationsbetween the various identifiers (e.g., session identifiers, browseridentifiers, device identifiers). In this regard, a particular userdevice 120 (as identified by a device identifier) may be associated withone or more sessions and browsers (or other applications). Theidentifier server 140 may therefore be capable of identifying one ormore such identifiers (whether website, browser, session, or device)based on examination of received data packets. The identifier server 140may store associations between various indicators by creating andupdating tables. For example, secure sessions (e.g., secure socket layer(SSL)/transport layer security (TLS) sessions) may allow for sessionresumption, which occurs where a client and server negotiates SSLinformation and then later reuses that negotiated SSL information forfuture connections. SSL session setup is generally very time-consuming,so not having to renegotiate is therefore desirable. In order to resumea session, a client must be able to identify the session. SSL/TLSsession IDs and/or TLS session tickets are two mechanisms that allow forthe identification and resumption of a previously selected session.

The identifier server 140 may be called when a browser visits websiteswith certain scripts (e.g., that call on the domain of the identifierserver 140). The identifier server 140 may therefore be able to receivesession resumption data when a particular website is accessed. As such,such identifier server 140 may use such session information to determinewhen multiple connections are using the same TLS session as indicated,for example, by the same SSL session ID. Thus, the identifier server 140can assign the same browser ID to multiple sessions or map differentbrowser IDs associated with the multiple connections together. Such amap constructed by the identifier server 140 allows for creation of apersistent set of indicators that can be used to recognize a browser infuture connections even when there is no existing SSL session that isbeing resumed.

Additional indicators may be based on use of transmission controlprotocol (TCP) information. TCP is used by a variety of Internet-basedapplications, including web browsers, email, and other applications.Information associated with use of TCP by a particular device (e.g.,present in a TCP packet) may be inclusive or indicative of varioustimestamp information. Other time-related information may be associatedwith a TCP packet, including current time, uptime (or epoch time), andclock skew. In an exemplary embodiment, the identifier server 140 mayreceive a packet (e.g., associated with TCP timestamp information, suchas a particular current time, uptime (or epoch time), source IP address,clock skew) of a selected session, determine whether the associatedtimestamp information (e.g., epoch time) of a packet matches anytimestamp information of a previously received packet that may beassociated with a selected session, and if so, drawing an associationbetween the sessions. Further, a stored packet list may be maintainedwith associated identifiers or other indicators that may be used to makeassociations among different identifiers (e.g., different deviceidentifiers for the same device) or to assign the same identifier todifferent session.

While client timestamp is generally included in the TCP packet andserver timestamp is generally added automatically when the TCP packet isreceived by the server, further calculations may also be applied todetermine other timestamp related information (e.g., epoch time andclock skew). The client timestamp, for example, provides a measure oftime typically reflective of the elapsed time since a computing devicewas started and continuously working. Especially when combined withother indicators (e.g., clock skew), the calculated epoch time (when thedevice was last started) may be able to uniquely identify a particulardevice as all packets for that device received within some window oftime of each other would share the same calculated epoch time. Withrespect to client timestamp, a device may record and report an elapsedtime since the last time the device was started or the elapsed time wasreset. That elapsed time may reset based on different schedules fordifferent computing devices (e.g., some devices reset every few days andothers reset every few weeks). Elapsed time may increment with adifferent granularity for different devices and operating systems. Thegranularity of the increment is measured in ticks. A tick may alsorepresent a different amount of time for different systems, so there maybe some device-specific calculations involved to determine type ofdevice by determining the amount of time represented by a tick. Theresult is a timestamp that is incrementing consistently. Calculatingthat backwards provides the epoch time, which may be the time the devicewas last started or the last time the timestamp was reset. As such, theepoch time generally remains the same even elapsed time increases, untilsuch time that the timestamp is reset.

Such indicators used by identifier server 140 may therefore includesession identifiers (e.g., transport layer security (TLS), securesockets layer (SSL)), transmission control protocol (TCP) identifiers(e.g., epoch time, current time, clock skew), internet protocol (IP)address, user agent identifiers, and others. Such indicators may be usedindividually or in any combination (e.g., SSL session identifier and TCPtimestamp) to identify a particular common browser and/or a particularuser device 120 based on common matches. An exemplary embodiment mayselect a certain set of indicators based on their respectivedeterministic value in identifying connections between identifiers fordifferent browsers or devices. For example, a SSL session identifier isunique to a collection of one or more sessions and can therefore be usedto associate different browser identifiers for the same browsertogether, as well as to assign the same browser identifier to differentsessions associated with the same browser and device. Likewise, thecombination of current time, epoch time, clock skew, and source IPaddress is unique to a particular device, thereby allowing forconnections to be drawn between different identifiers associated withthe device.

For example, a particular request to download website may refer to anidentifier that is associated with one or more indicators (e.g., SSLsession identifier). Such SSL session identifier may be compared tostored information and determined by identifier server 140 as havingbeen previously used in conjunction with the same or different browseridentifier and/or device identifier. Likewise, an epoch time associatedwith the requesting computing device may be determined by identifierserver 140 as having been previously identified or used in conjunctionwith the same or other browser identifiers and/or device identifiers.The browser identifier—which may be associated with the timestamp and/ordevice identifier—may be encrypted, and unauthorized parties maytherefore be unable to access, view or decrypt such encryptedinformation.

Information regarding identifiers may be stored in a table, which mayfurther include a list of identifiers determined to be associated withthe same browser, application, session, or device. Where no stored tableexisted for the referenced identifier (or any of its associatedindicators or identifiers), a new table may be created. Where a storedtable does exist, such stored table may be updated. As such, tableshaving one or more of these identifiers may be created and updated basedon newly incoming identifiers (associated with certain indicators) andmatches with stored identifiers (associated with the same or differentindicators). When the identifier server 140 finds that two differentidentifiers have the same indicator (e.g., SSL session identifier), forexample, the identifier server 140 may determine that the respectivesessions are originating from the same device. The lifespans,availability, and uniqueness of each indicator may vary across differentbrowsers, user agents, and/or operating systems. As such, indicators maybe used in combination to exclude certain devices, for example, therebyfacilitating the search for a match.

In some embodiments, a first party cookie—which may include a token orcontainer of encrypted identifier(s) and associated information—may beused to store the persistent identifier for each website on the browser.Although such a cookie may persist for a time, such cookie may bechanged periodically, as well as re-encrypted to prevent the encryptedidentifier itself from being used as an identifier by unauthorizedparties. Thereafter, various matching parameters (e.g., SSL and epochtime) may be used to identify and to draw associated cookies together asdescribed in further detail below. In that regard, the identifier server140 should be understood as having the ability to use any persistentidentifier to associate to other persistent identifiers. Over time,therefore, the tables constructed by the identifier server 140 may growto identify new connections and associations between variousidentifiers.

Service providers 150 may include servers or other computing devicesthat may provide various services based on identification of a browser.For example, a service provider 140 may use information regarding repeatvisits to provide targeted advertising to repeat visitors (versusfirst-time visitors).

FIG. 2 is a flowchart illustrating an exemplary method 200 fortimestamp-based session association. The method 200 of FIG. 2 may beembodied as executable instructions in a non-transitory computerreadable storage medium including but not limited to a CD, DVD, ornon-volatile memory such as a hard drive. The instructions of thestorage medium may be executed by a processor (or processors) to causevarious hardware components of a computing device hosting or otherwiseaccessing the storage medium to effectuate the method. The stepsidentified in FIG. 2 (and the order thereof) are exemplary and mayinclude various alternatives, equivalents, or derivations thereofincluding but not limited to the order of execution of the same.

Method 200 may be used to allow for timestamp-based session associationdespite various network anomalies and inconsistencies that may occurover time. When network jitter is present, data packets sent from thesame device 120 may experience variations in timestamp data.Timestamp-based metrics—including skew—may therefore seem to vary. Tocompensate for such irregularities, method 200 may evaluate packets thatare received over time. Such packets may be associated with a uniqueidentifier for a session of a device 120. Identifying epoch time matchesmay then allow for identification that multiple sessions belong to thesame device 120 (e.g., based on common epoch times) despite beingassociated with different device identifiers, browser identifiers, TLSSession IDs, user agents, etc. Although the steps are illustrated anddescribed in sequence, some steps may be performed concurrently or in adifferent order.

In step 205, data packets may be retrieved from a data store for apredefined window of time (e.g., last 24 hours of a current session).Data packets may be sent from one or more of the user devices 120A-Doperating a network-enabled application, such as a browser, and arereceived and captured at identifier server 140. Over the course of thepredefined window of time, further, data packets associated withdifferent sessions may have been received. The retrieved data packetsmay have been identified as likely to be associated with the sameaddress based on various matching identifiers, including IP address,port, computing device timestamp, server timestamp, device identifier,browser identifier, user agent, operating system and version, sessionidentifier (and/or other session information, including ticket, starttime), and other information. The period of time during which the datapackets are captured may be configurable.

In step 210, the retrieved data packets may be sorted by time of receipt(e.g., from most recently received to oldest) as indicated by the servertimestamp.

In step 215, the set of packets being evaluated may be filtered based onvarious factors, including session, device of origin, time of receipt(e.g., last 24 hours), etc. In addition to removing packets that may notbe useful for identifying associations to the same device, filtering forcertain factors may result in identifying a set of packets as likely tobe associated with the same device. Data packets not meeting theparameters of interest may be discarded from further evaluation. Forexample, in step 220, data packets may be filtered out based on nothaving any timestamp information. Further, the set of packets may berefined based on time of receipt in steps 230 (too recent) and 235 (tooold).

In some embodiments, packets may also be discarded from evaluation forbeing outliers. Further, anomalies may arise when a computing devicegoes into sleep mode during which the clock may run much more slowly.Outlier packets may be identified based on falling into a predeterminedpercentile (e.g., 95th percentile) with respect to difference betweencomputing device timestamps and server timestamps. If the difference ismuch larger than expected (e.g., 95th percentile), for example, thepacket may not be selected for inclusion in calculations andcomparisons.

After the list of packets has been filtered, two packets are selectedfor analysis with respect to skew. Because network latency may not beconstant, selecting different sets of packets may result in differentskew values due to variations in when the server receives a packet(which results in variable differences between computing devicetimestamp and server timestamps). The selected packets may be the mostrecently received packet and the next most recently received packet thatwas received at least a predetermined time period (e.g., at least onesecond) from receipt of the most recently received packet. In otherimplementations, the most recently received packet and the oldestreceived packet may be selected.

In step 240, the most recently received packet in the retrieved list isset as the last known packet. In step 245, the next most recentlyreceived packet may be searched for that was received at least apredetermined minimum of time (e.g., at least one second later) fromreceipt of the last known packet. In step 250, it may be determinedwhether the next packet was found. If not, the method exits without anydevice matches. If the next packet was found, the method process to step255.

In step 255, a skew may be calculated. To calculate the skew, the datapackets received from the same session or identifier may be furtheranalyzed together (e.g., two data packets received at least apredetermined time interval apart). Each data packet is associated witha computing device (client) timestamp and a server timestamp. Thecomputing device timestamp is placed in the packet by the computingdevice 120 under TCP protocol. The computing device timestamp representsan amount of time since the computing device was restarted (or thetimestamp reached is maximum value and rolled over). The servertimestamp is the actual time that the packet was received according tothe server clock. In general, both the server timestamp and thecomputing device timestamp advance consistently over time, although thedevice timestamp may exhibit more drift (as servers may be subject totimestamp adjustments that reduce or eliminate the effects of suchdrift).

As described, skew may represent the speed at which a client (e.g.,computing device) clock is incrementing in comparison to a server clock.As such, a skew value may be a difference in the rate of advance of theclient timestamp and the server timestamp, which may be due todifferences in CPU architecture, clock speed, and other differencesbetween the client and the server. Skew may be calculated as follows:

skew=(p1.c_ts−p2.c_ts)/(p1.s_ts−p2.s_ts)

where p1.s_ts is the server timestamp of a first selected data packet(e.g., most recently received within time window), p.2s_ts is the servertimestamp of the second selected data packet (e.g., received at least apredetermined time before the first packet), p1.c_ts is the computingdevice timestamp of the first packet, and p2.c_ts is the computingdevice timestamp of the second data packet.

In step 260, the session identifier associated with the last knownpacket may be added to the known session list, and in step 265, the nextpacket in the retrieved list may be evaluated.

In step 270, an epoch time may be calculated for e ach packet. Asdescribed, epoch time represents an amount of time since the client(e.g., computing device) timestamp was at zero. Such epoch time may becalculated as follows:

Epoch time=s_ts−(c_ts/skew)

where skew is calculated as discussed above with respect in step 255.Following performance of step 270, each data packet being evaluated maybe associated with an epoch time. In some embodiments, the first packetin the set (e.g., where there is no previously received packet) maysimply be assigned the first epoch time. Further, in someimplementations, skew may be calculated for different sets of packetsand then averaged for use in calculating epoch time.

In step 275, it may be determined whether the session identifierassociated with the next packet is found in the known session list. Ifyes, the method proceeds to step 280, in which the next packet isdesignated the last known packet. If the session identifier associatedwith the next packet is not found in the known session list, the methodproceeds to step 285, in which it may be determined whether the epochtime of the next packet matches the epoch time of the last known packet.A match may be found when two epoch time values are within a predefinedrange. As such, minor variations may nevertheless result in a match. Insome embodiments, the epoch time from the current session may becompared to the last epoch time that is known to match. Subsequentmatches may use the most recent epoch time for matches, because epochtime may exhibit some change due to drift over time. Allowing apredefined range, and using the most recent epoch time may thereforecompensate for any drift.

A match indicates that the associated data packets likely originatedfrom the same device. If an epoch time match is found, the methodproceeds to step 280, in which the next packet is designated the lastknown packet. From step 280 and where the epoch times do not match, themethod proceeds to step 290, in which it may be determined whether thereis another packet in the retrieved list. If yes, the method reverts backto step 265, in which another next packet in the list may be obtainedfor evaluation. If there is no other packet in the list, the method mayexit with an updated known session list, which may be used to updatevarious databases with respect to the newly determined matches betweendifferent session identifiers. Such updates may include merging ofvarious fields (e.g., in stored table) to include information regardingthe data packets having an epoch time matching a primary epoch timeassociated with the stored table, which may be associated with a deviceidentifier. As such, multiple identifiers may be determined to beassociated with the same device, and information regarding the differentidentifiers may be incorporate or otherwise merged into a combinedrecord that corresponds to a common device.

A primary device identifier may be designated. Where multipleidentifiers have been assigned to a device, one identifier may beselected to be designated as the primary identifier for the table. Forexample, the most recently assigned device identifier associated withthe device may be designated as the primary identifier, which may thenbe associated with subsequently assigned secondary identifiers. As such,the primary identifier associated with a specific device may bemaintained and updated (e.g., re-encrypted) as necessary in light ofnetwork anomalies and jitter effects. In subsequent interactionsinvolving one of the associated secondary identifiers, for example, the(encrypted) primary identifier may be exchanged via an encryptedidentifier container or token.

The method 200 may be iterated:

-   -   k=n (set the known packet as the first packet)    -   sessionList.push(packet(k). sessionid)    -   n=n+1 (increment the packet index)    -   while n<packetList.length (there are more packets to process)        -   if packet(n).sessionid is in sessionList        -   k=n (make this our last known packet)        -   else        -   if packet(n).epochtime matches* packet(k).epochtime            -   k=n (make this our last known packet)                -   append packet(n).deviceid to sessionList (remember                    device)        -   n=n+1 (increment the packet index)            where n is the index of the packet in the array, k is the            index of the last packet for the known device, sessionList            is a list of all session that have been determined to be the            same device as the initial known session (including the            initial known session to start), and matches refers to            values that are within a predetermined, configurable time            period.

Some embodiments may include generating mutable and immutable browseridentifiers and mapping the immutable and browser identifiers to eachother based on indicators (e.g., epoch time) of common session and/ordevice. As indicated by their respective names, an immutable browseridentifier does not change, while a mutable browser identifier maychange. An immutable browser identifier may be associated or mapped todifferent mutable browser identifiers. Because a mutable browseridentifier may change, various indicators associated with a referencedmutable browser identifier may be used to map that referenced browseridentifier to the immutable browser identifier, its associated mutablebrowser identifiers, and/or an associated device identifier.

A mutable browser identifier object may be stored in any type of filethat may be maintained in local browser memory storage, includingstylesheets, JavaScript files, HTML files, text files, AJAX requests,image files, cookies, etc. Such mutable browser identifier object mayallow for its content (including the mutable browser identifier, whetherunique or non-unique) to be accessible to the browser and relatedbrowser applications (including a loader application). As such, thebrowser and related browser applications may access and use theencrypted identifier for various operations, including logging activity.

A mutable browser identifier object may include a mutable browseridentifier, which may be unique to the webpage. In some cases, the usermay opt out of being provided with a unique mutable browser identifier.In such cases, a new mutable browser identifier object may be generatedwith a non-unique term as the mutable browser identifier. Alternatively,the mutable browser identifier object may be updated to replace theunique identifier with a non-unique term (or an opt-out identifier fordefined or general opt-out). As such, a mutable browser identifier maynot be provided to the browser for storage in some instances.Alternatively, a mutable browser identifier may be provided that canonly be decrypted at the identifier server 140. Separately, a non-uniquemutable or immutable identifier may be provided that indicates that theuser opted out of unique identifier use.

In some embodiments, the mutable browser identifier object may furtherinclude other types of information regarding user preferences (asdesignated by the user), including information regarding user opt-outsor opt-ins for specific webpages, websites, vendors, or specific typesof data use. As the user changes their opt-out or opt-in settings, suchinformation may be used to update a mutable browser identifier object.The browser may then be directed to reload the mutable browseridentifier object into the local browser storage, thereby implementingthe updated user settings.

FIG. 3 is a flowchart illustrating an exemplary method 300 fortimestamp-based matching of identifiers. In method 300 of FIG. 3 ,identifier information may be stored in memory of an identifier server140, a reference to a browser identifier may be received, and it may bedetermined whether there is a timestamp and IP address associated withthe referenced browser identifier. If not, the method may proceed todetermine whether the referenced identifier corresponds to a deviceidentifier, and if not, a device identifier may be created and encryptedin conjunction with one or more other identifiers and related data(e.g., in an encrypted container or token). The referenced identifiermay also be decrypted to provide one or more identifiers (e.g., device,browsers, and/or websites). Stored information associated with thecorresponding stored identifier may be updated based on the deviceidentifier (and its associated information) and associated browseridentifier and other associated identifiers.

If there is no reference browser identifier but there is a matchingepoch time, the identifier associated with the matching epoch time ofthe current session may be encrypted and returned to the browser. Ifthere is there is a reference identifier that has a matching epoch timeassociated with a different identifier, one may be selected as theprimary identifier. That primary identifier may be returned (inencrypted form) to the browser. If the reference Identifier has nomatching epoch time, the same reference identifier may be returned (inre-encrypted form). If the reference identifier is the same as anidentifier associated with a matching epoch time, the same identifiermay be returned (in encrypted form). In all cases, the identifier thatis being returned is encrypted (or re-encrypted) using a new encryptionkey so as to always be different than the reference encryptedidentifier.

In step 305, identifier information may be stored in local browserstorage for a website. Such identifier information may be provided by anidentifier server 140 that keeps track of multiple different mutablebrowser identifiers, immutable browser identifiers, and deviceidentifiers, as well as correlations among such identifiers. Forexample, a particular device identifier may be associated with one ormore mutable browser identifiers and immutable browser identifiers. Suchmaps may have been generated based on previously received informationregarding such associations (e.g., previously received browseridentifiers mapped to a particular common device identifier), as well asupdated over time. Such updates may include not only creating newassociations based on newly received association data, but also updatingstored associations based on any matches to the newly receivedinformation. In some embodiments, a container or token may be generatedbased on an assigned device identifier, browser identifier, andassociated metadata and other information.

In some embodiments, the mutable browser identifier may be stored in anencrypted container. One specific example may be referenced herein as anencrypted identifier (EID) container. Such EID container may be storedin local browser storage in association with an executed script (e.g.,in the name space of each participating website such as webpage 410 ofFIG. 4 ). Such EID container may have been generated (and/or updated) byan identifier server 140 and placed on the website by a publisher,whether via a tag manager or header bidding integration (e.g.,prebid.js). In some embodiments, the EID container may be stored as acookie (e.g., named_parrable_id or a different name).

In step 310, a request may be received at identifier server 140 from thebrowser of a user device 120. Such request may be automatically sent bythe browser in association with a request for a particular website(e.g., as identified by a URL) that may be entered by the user of theuser device 120, which may send such request to the server 130associated with the website. The server 130 provides website content tothe browser of user device 120. Such website content may be associatedwith the reference to a browser identifier object. Such a reference maybe another URL that resolves to identifier server 140. In someembodiments, the reference sent by the server 130 may pertain to aloader application that is executable to reference the browseridentifier object. In some instances, the browser may check localbrowser storage to find the referenced browser identifier object thatmay already have been downloaded previously.

Following such checking of the local browser storage, the user device120 may send a request to an identifier server 140 associated with thereferenced mutable browser identifier object. Such request may beindicative of whether the referenced mutable browser identifier objectwas found in the local browser storage (and if so, when the referencedmutable browser identifier object had been created). Where the requestindicates that the referenced mutable browser identifier object was notfound in the local browser storage, the identifier server 140 may followthe workflow that includes generating a new mutable browser identifierobject to the user device 120. As noted above, the new mutable browseridentifier may be generated so as to be unique to the particular websitebeing downloaded (e.g., based on website domain or othercharacteristic).

In step 315, it is determined whether a timestamp (e.g., TCP timestamp)is associated with the request received in step 310. If not, the methodproceeds to step 320, and if yes, the method proceeds to step 335. Asdiscussed above, a timestamp (including epoch time or uptime) may beassociated with each data packet received by identifier server 140. Thetimestamp may be used by the identifier server 140 to match the currentset of data packets from a particular device to packets previouslyreceived in a past session or different browser. For example, theidentifier server 140 may further be able to match mutable browseridentifiers to a common immutable browser identifier, as well as to acommon device identifier. In this regard, a particular user device 120(as identified by a device identifier) may be associated with one ormore browsers (as identified by a respective immutable browseridentifier), each of which may be associated with one or more websites(as identified by a respective mutable browser identifier). Theidentifier server 140 may therefore be capable of identifying one ormore such identifiers (whether website, browser, or device) when a userdevice requests a website using particular browser, as well asmaintaining and updating maps regarding which identifiers are associatedwith each other.

In step 320, it is determined whether the current packets are associatedwith a device identifier. Where the browser provides an EID, theidentifier server 140 may access the device identifier within an EIDcontainer by decrypting the EID container. The decrypted EID containermay then yield a device identifier, as well as associated browseridentifiers and related metadata and information.

If the packets are not associated with any device identifier, the methodmay proceed to step 325 for generation of a new (primary) deviceidentifier. In that regard, the identifier server 140 may generate andprovide a new unique mutable browser identifier upon request. Such aunique mutable browser identifier may be specific to the website makingthe request. Where the user may have opted out, however, a non-uniqueterm may be inserted in place of the unique mutable browser identifier.In some embodiments, the user may opt out of being provided with uniqueidentifiers with respect to a designated webpage or website.Alternatively, the user may opt into being provided with uniqueidentifiers with respect to a designated webpage or website. As such,the website may be uniquely identified via the unique mutable browseridentifier for some webpages, but not others. In some embodiments, suchinformation regarding user opt-outs or opt-ins may be reflected in themutable browser identifier object. For example, the mutable browseridentifier object may include information indicative of the user opt-inor opt-out for defined webpages, websites, or categories of websites, aswell as indicators specifying the granular details under which theopt-in or opt-out are to be implemented.

The user may also opt to reset the unique mutable browser identifierassociated with the website. Resetting the unique mutable browseridentifier may involve clearing the local browser storage of anypreviously downloaded mutable browser identifier objects, generating anew mutable browser identifier (in a new mutable browser identifierobject), and providing the new mutable browser identifier object, whichmay then be stored in the local browser storage. In some embodiments, asignal may be sent to the identifier server 140 to indicate that themutable browser identifier object needs to be updated. Such a signal maybe implemented in a cookie that the identifier server 140 can read andthen determine what to send back as the mutable browser identifierobject. Alternatively, the request (including pass information orparameters) may be directed to a transient URL (e.g., that is structuredto include the mutable browser identifier and any directives), and thatrequest may then be redirected to the identifier server 140, which canthen look at the referrer header (e.g., transient URL) of the request toparse out the requested changes to the mutable browser identifierobject.

Further, the identifier server 140 may provide a plurality of mutablebrowser identifiers (each to a different website and provided in adifferent mutable browser identifier object). Activity at the userdevice 120 in relation to the website may thereafter be associated withthe provided unique mutable browser identifier. Such mutable browseridentifier may further be associated with immutable browser and/ordevice identifiers, thereby allowing for the ability to distinguishbetween different browsers on the same or different computing devices insome cases. Specifically, information may be logged regarding activityat a particular website (as identified by a unique mutable browseridentifier), which may be provided to identifier server 140 (or anassociated server) by a loader application at the user device 120. Inthat regard, the identifier server 140 may not receive the mutablebrowser identifier itself, as the mutable browser identifier may only becalled by local applications or code (e.g., browser, loader application,local code library) resident on the user device 120. The loaderapplication may be executed to perform a variety of functions, which mayinclude loading and executing code from the code library. Such a codelibrary may be provided, modified, and updated at the web server 130,identifier server 140, or other designated service provider 150.

In some embodiments, the browser may not necessarily request that theidentifier server 140 validate the referenced mutable browser identifierobject. In such instances, the browser may use the stored mutablebrowser identifier object without making any request to the identifierserver 140. Because the identifier server 140 provides the mutablebrowser identifier in encrypted (or re-encrypted) form, the browser maybe provided with a different encrypted version of the mutable browseridentifier in response to teach request. As discussed above, suchencryption may be applied to a container that includes multipledifferent identifiers that are associated together and with otherinformation. An example of one such encrypted identifier (EID) containermay take the following form:

-   -   xx.yyyyyyyyyy.zzzzzzzzzzzzzzzzzzzzz    -   xx=2 digit version indicator that may allow or addition of a        conditional for encryption and decryption so as to be able to        change versions.    -   yyyyyyyyyy=the timeIndex or 10 digit time stamp (without ms)        that may be created in node.js as follows Math.trunc(Date.now(        )/1000) and that may be used to lookup the encryption key.    -   zzzzzz . . . =encryption key whose length may vary.

The encrypted block of the EID container can further contain a varietyof information. By storing information in the EID container, the browsermay serve as a portal to distributed storage that only the identifierserver 140 and authorized partners are able to decrypt. By providingencryption keys in near real-time, further, identifier server 140 canalso turn off a bad actor or otherwise prevent bad actors from accessingthe information in the EID container.

When the website is accessed by a device, a request may be sent by thebrowser having a reference to any existing EID container. A new EIDcontainer may be recreated (including by re-encryption) with everyactivation by a requested webpage view, thereby preventing any part ofthe EID container from being used as a stable identifier over time. —TheEID container may further specify a version identifier, and anencryption key index used to find the right key for the specifiedversion. The version may be graded as part of the process in which anold version of the EID container may be discarded in favor of a newversion.

Each time that the identifier is activated (e.g., through javascript oranother mechanism in relation to a webpage view), a new EID containermay be generated using a new encryption key. If two activations happenedin the same second for the same browser on the same device on the samewebsite, however, the same EID may be generated twice. Additionally, theversion of the old EID container and new EID container may differ if thecurrent version specified by an encryption service may have changed. Byre-encrypting the EID container with a new encryption key at intervalsor for each response, the contents of the EID container may be preventedfrom being used as a stable identifier, which assures that only thosethat can decrypt the EID container are able to access the identifierscontained therein.

As such, a device identifier is created to uniquely identify thecomputing device that referenced the browser identifier. In someembodiments, the device identifier may be associated with the browseridentifier, as well as other related information, and packaged into anEID container. An exemplary process for creating such a container mayinclude encoding the associated data, encrypting the encoded data, andbuilding an encrypted identifier may include the following:

-   -   1. Provide validation portion to verify integrity of        encrypted/decrypted data, which may include creating a buffer        with 16 zeros (the AES-256 block size) to serve a similar        function as cryptographic hash function (e.g., HMAC) used for        decryption)    -   2. Convert the browser identifier created time to a 13 byte        buffer and convert a universally unique identifier (UUID) of the        browser identifier to a 16 byte buffer    -   3. Convert device identifier and device identifier created time        accordingly    -   4. Concatenate the identifiers in that order into a block    -   5. Encrypt the block using AES265 and the encryption key that        corresponds with time stamp (without ms) of the impression    -   6. Convert the encrypted text to a hex string    -   7. Prepend the version and the timeIndex

In some embodiments, therefore the browser identifier may be associatedwith device identifier, along with additional data (e.g., creationdates), within the encrypted block or container. The version of thebrowser identifier may be used to determine and inform the encryptionand decryption processes.

When identity server 140 receives a request from a browser (e.g., webpage view), therefore, the identity server 140 may be activated todecrypt any EID container that is present in the request, as well asproceed with session matching as discussed earlier herein. A(re)encrypted EID container (encrypted with a new encryption key) isfurther returned to the requesting browser. The associated encryptionkey may thereafter be used to reverse the process for decryption anddecoding by identity server 140 or by authorized partners. The 16 zerosmay be used to test that the key used for decryption was valid. Ifdecryption does not produce the 16 zeros, the encryption key may beinvalid. In some instances, there may be heightened security risk, andan HMAC may be encrypted along with the browser identifier. Theencryption keys used to encrypt (and decrypt) the identifiers may bepre-generated a certain time period (e.g., a week) in advance andstored. Generation of an encryption key may be based on cryptographicfunctions, which may be random.

If the packets are already associated with an identifier, the method mayproceed to step 335. In step 335, the primary device identifier may beidentified. In cases where the same timestamp may be associated withmultiple different device identifiers, for example, one deviceidentifier may be identified as the primary device identifier. Any otherdevice identifiers may be designated as secondary device identifiers.

In step 345, the identified primary device identifier may thereafter beused to identify further matches. In step 350, it may be determined asto whether there are other matches associated with different sessions.Such matches may be identified, for example, by determining whether theepoch time associated with the selected primary device identifiermatches the epoch time of packets in previous sessions. If there is nomatch, the method may proceed to step 355 in which the same primaryidentified may be used for step 330. In If there is a match, the methodmay proceed to step 360, which associates the identified matches to theprimary device identifier.

As noted above, some indicators may have different deterministic value.While improbable, it is possible that two different computing devicesmay have the same epoch time. As such, the referenced browser identifiermay be associated with a different computing device (having a differentdevice identifier) than the computing device that that referenced thebrowser identifier. Conversely, the matching methodologies discussedherein also allow for different device identifiers to be identified asbeing associated with the same device.

In step 330, the primary device identifier—in conjunction withassociated secondary and other identifiers and other information—may beencrypted (or re-encrypted) with a new encryption key. Thenewly-encrypted device identified, which may now be part of an EIDcontainer, may then be provided to the browser. As such, the browser maymaintain the EID that includes a different version (encrypted with thedifferent encryption key) of the device identifier associated with theparticular device. As such, the activity of that device (e.g., acrossdifferent browsers, sessions, and websites/applications) may beidentified as belonging to a common device.

FIG. 4 is a diagram illustrating an exemplary network environment inwhich a system for assignment and use of encrypted identifiers may beimplemented. As illustrated, such a system may include identity cluster420, data management platform (DMP)/data providers 430, decryptioncluster 440, supply side platform (SSP) partners 450, and DSP 460.

In an exemplary implementation, a user request may be received via abrowser concerning a webpage 410 from an identifier-enabled publisher.The browser may load the requested webpage 410, which may contains ascript (e.g., parrable.js JavaScript) that is executable to send arequest an identifier from identity cluster 420. Such identifier mayinclude the encrypted identifier (EID) contained in a cookie that may bepresent (e.g., _parrable_id cookie). In some embodiments, such cookiemay further include tags (e.g., data partner tags from data providers430, SSP tags from SSP partners 450).

Decryption cluster 440 may then decrypt and decode the EID container,for example, be using the version of the EID container to determine howdecryption and decoding are to be performed. The timestamp may be usedto lookup the necessary encryption key. Once the browser identifier isdecrypted, the identifier server 140 may perform the methods of FIG. 2or FIG. 3 in order to determine other identifiers (e.g., mutable browseridentifiers, other associated browser identifiers, device identifiers),as well as update associated tables and maps. The identifiers may be thesame as those contained in the EID container (if one was provided) ormay be different (e.g., if the algorithms determine that the identifiersneed to be updated).

The identifiers may be encoded into a byte array, which may then beencrypted using the appropriate version and encryption key for thecurrent second. The EID string may then be built to include the version,timeindex, and encrypted data, and the new EID container may be sentback to the browser. The browser may store the EID container locally,and when a new request is made regarding the webpage 410, the processmay be repeated.

In addition, third party partners may be provided with the EID containerto associate with different webpages, applications, etc. In addition,authorized parties may be allowed to decrypt the EID containers toaccess the encrypted identifiers contained within. The EID container maytherefore be decrypted by parties with access to the encryption keys andalgorithms, which may be accessed via a representational state transfer(REST) application programming interface (API)—or another type ofAPI—associated with the identifier server 140. The decryption can takeplace through the REST service associated with the identifier server140, or the parties may be provided with the decryption algorithms(and/or certificates, access keys, etc.) for integration into theirrespective systems. Such parties may further be provided with a feed ofencryption keys (e.g., from identifier server 140 or related system).

DMP/data providers 430 may collect or otherwise receive data fromvarious sources, associate data sets with respective EID containers, andprofile activity associated with the EID containers. As such, DMP 430may be permitted decrypt the encrypted browser identifier. A deviceidentifier may be used to onboard data and build audience profiles. Suchprofiles may be provided to other parties (e.g., demand side platform(DSP) 460).

DSP 460 may be a different type of entity that interacts with both DMP430 on behalf of SSP 430. For example, DSP 460 may place advertisementcampaigns across different websites and applications, each of which maybe associated with an EID container. Contextual data regarding the EIDcontainers may include browsing history or other types of site orapplication activity, which may be indicative of demographic or otherdata useful for targeted advertising to audience segments. Conversely,DSP 460 may also assist website-affiliated entities to find appropriateadvertising to place of their respective websites.

Meanwhile, SSP partners 450—which may include either the advertisingentity or the website affiliated entity—may use the EID containers toprovide DSPs 460 with information that will facilitate targetedplacement. In an exemplary embodiment, an auction may be implemented inwhich the SSP 560 request bids associated with EID containers (e.g.,indicative of browsing history types), which may be submitted by DSP460. The bids may be automatically evaluated and matched in accordancewith the EID containers and associated audience profiles. Such DMP 430and SSP 450 may be authorized parties that may be provided with theability to decrypt the EID container. Such parties may implement theencrypted identifier system described herein for the purpose ofdistinguishing unique impressions (e.g., by different browsers anddevices).

In some embodiments, the EID container may not use AES256, but insteaduses an algorithm, such as chacha20poly1035 and built in HMAC or anotheralgorithm, which allow the decrypted data to be validated. Additionally,the new EID container may contain additional information beyond just thebrowser identifiers and creation dates. Key management may also beadjusted to use fewer keys, though a new key may be used for everysecond of the day to minimize the chance that the same EID containerwould occur twice.

Further embodiments may use an additional type of encrypted identifierfor devices associated with users who have or have not consented tosharing their information, as well as specific permissions andrestrictions regarding how such information is to be used. Suchencryption may be restricted from being used by outside parties, as wellas compliant with applicable privacy rules and regulations (e.g.,California Consumer Privacy Act (CCPA), (GDPR)).

FIG. 5 illustrates an exemplary computing system 500 that may be used toimplement an embodiment of the present invention. System 500 of FIG. 5may be implemented in the contexts of the likes of user devices 120A-D,server 130, identifier server 140, and service provider 150. Thecomputing system 500 of FIG. 5 includes one or more processors 510 andmemory 510. Main memory 510 stores, in part, instructions and data forexecution by processor 510. Main memory 510 can store the executablecode when in operation. The system 500 of FIG. 5 further includes a massstorage device 530, portable storage medium drive(s) 540, output devices550, user input devices 560, a graphics display 570, and peripheraldevices 580.

The components shown in FIG. 5 are depicted as being connected via asingle bus 590. However, the components may be connected through one ormore data transport means. For example, processor unit 510 and mainmemory 510 may be connected via a local microprocessor bus 590, and themass storage device 530, peripheral device(s) 580, portable storagedevice 540, and display system 570 may be connected via one or moreinput/output (I/O) buses 590.

Mass storage device 530, which may be implemented with a magnetic diskdrive or an optical disk drive, is a non-volatile storage device forstoring data and instructions for use by processor unit 510. Massstorage device 530 can store the system software for implementingembodiments of the present invention for purposes of loading thatsoftware into main memory 510.

Portable storage device 540 operates in conjunction with a portablenon-volatile storage medium, such as a floppy disk, compact disk (CD) ordigital video disc (DVD), to input and output data and code to and fromthe computer system 500 of FIG. 5 . The system software for implementingembodiments of the present invention may be stored on such a portablemedium and input to the computer system 500 via the portable storagedevice 540.

Input devices 560 provide a portion of a user interface. Input devices560 may include an alpha-numeric keypad, such as a keyboard, forinputting alpha-numeric and other information, or a pointing device,such as a mouse, a trackball, stylus, or cursor direction keys.Additionally, the system 500 as shown in FIG. 5 includes output devices550. Examples of suitable output devices include speakers, printers,network interfaces, and monitors.

Display system 570 may include a liquid crystal display (LCD) or othersuitable display device. Display system 570 receives textual andgraphical information, and processes the information for output to thedisplay device.

Peripherals 580 may include any type of computer support device to addadditional functionality to the computer system. For example, peripheraldevice(s) 580 may include a modem or a router.

The components contained in the computer system 500 of FIG. 5 are thosetypically found in computer systems that may be suitable for use withembodiments of the present invention and are intended to represent abroad category of such computer components that are well known in theart. Thus, the computer system 500 of FIG. 5 can be a personal computer,hand held computing device, telephone, mobile computing device,workstation, server, minicomputer, mainframe computer, or any othercomputing device. The computer can also include different busconfigurations, networked platforms, multi-processor platforms, etc.Various operating systems can be used including Unix, Linux, Windows,Macintosh OS, Palm OS, and other suitable operating systems.

The present invention may be implemented in an application that may beoperable using a variety of devices. Non-transitory computer-readablestorage media refer to any medium or media that participate in providinginstructions to a central processing unit (CPU) for execution. Suchmedia can take many forms, including, but not limited to, non-volatileand volatile media such as optical or magnetic disks and dynamic memory,respectively. Common forms of non-transitory computer-readable mediainclude, for example, a floppy disk, a flexible disk, a hard disk,magnetic tape, any other magnetic medium, a CD-ROM disk, digital videodisk (DVD), any other optical medium, RAM, PROM, EPROM, a FLASHEPROM,and any other memory chip or cartridge.

Various forms of transmission media may be involved in carrying one ormore sequences of one or more instructions to a CPU for execution. A bus(e.g., bus 590) carries the data to system RAM, from which a CPUretrieves and executes the instructions. The instructions received bysystem RAM can optionally be stored on a fixed disk either before orafter execution by a CPU. Various forms of storage may likewise beimplemented as well as the necessary network interfaces and networktopologies to implement the same.

While various embodiments have been described above, it should beunderstood that they have been presented by way of example only, and notlimitation. The descriptions are not intended to limit the scope of theinvention to the particular forms set forth herein. Thus, the breadthand scope of a preferred embodiment should not be limited by any of theabove-described exemplary embodiments. It should be understood that theabove description is illustrative and not restrictive. To the contrary,the present descriptions are intended to cover such alternatives,modifications, and equivalents as may be included within the spirit andscope of the invention as defined by the appended claims and otherwiseappreciated by one of ordinary skill in the art. The scope of theinvention should, therefore, be determined not with reference to theabove description, but instead should be determined with reference tothe appended claims along with their full scope of equivalents.

What is claimed is:
 1. A method for associating sessions based on timestamp data, the method comprising: retrieving a collection of data packets received during one or more sessions between a client device and a server computing device within a time period, each packet in the collection of data packets associated with an encrypted identifier unique to a respective session; decrypting the encrypted identifier of each of the data packets based on a respective version indicator; identifying an epoch time associated with the respective decrypted identifier of the retrieved data packets, wherein the epoch time is indicative of a last time that a respective timestamp of a respective one of the data packets was reset, wherein the calculated epoch time is based on the determined skew and respective timestamp information of the data packet; identifying whether each of the calculated epoch times matches a previously calculated epoch time for a packet associated with a previously selected session; and updating a list of sessions associated with the client device based on one or more identified matches between the respective calculated epoch time and the previously calculated epoch time. 